This is fairly ready, up to tests and release notes

I have a use case where I need to copy transpilation of multi-qubit circuits across different sets of qubits, for example doing mirror RB on three qubits across many disjoint sets of three qubits on a device, so it would be really useful if this can be extended to work for duplicating multi-qubit circuits in the scenario where all the qubit groups provided are the same length.

Regarding extending this -- @thaddeus-pellegrini and I wrote an extension based on the code here for ZZ measurements where we also want to measure between pairs of disconnected qubits. We can let this PR finish review and then make another PR with that extension to match whatever final form this PR takes.

@coruscating I'm not sure if I understand correctly the request. Possibly it's already supported.

mirror_rb_template_exp = MirrorRB([0, 1, 2], ..., backend=backend)

#One parallel circuit, encompassing experiments for the triplets [1, 5, 3], [4, 2, 0], [6, 7, 8]
groups = [[[1, 5, 3], [4, 2, 0], [6, 7, 8]]]

mirror_rb_whole_backend_exp = build_whole_backend_experiment(mirror_rb_template_exp, groups)

I see that there's interest in moving this forward.
@chriseclectic In a team meeting you had reservations about the interface. Maybe also @nkanazawa1989.
Can you please read again the proposed interface and comment on it?

@yaelbh Oh, I misunderstood you saying the experiment circuits are transpiled for only qubit 0 to mean that it wouldn't work for multiple qubit experiments like mirror RB. Then the framework should work for my use case as-is, thanks.

@coruscating Almost. The template experiment will be transpiled for qubits 0, 1, 2, taking into account the connectivity between them in the backend. For example, if qubits 0 and 2 are not connected, and you have a cnot gate between them, then the transpiled circuit will insert swap gates.
Now, if you provide in your groups a triplet of qubits with a different connectivity then you may get a bug. For example, if in your triplet the first and second qubits are not connected, while qubits 0 and 1 are connected, then the transpiled circuit may have 2q gates on the unconnected first and second qubits.

My main disagreement with this is the API. I don't like to unnecessarily introduce new APIs to do things when we already have an existing API for building and running experiments which could be used to accomplish the same task, as this adds fragmentation to the module design, and increases burden for documentation and users.

It seems what you really want is a hybrid parallel+batch experiment that is initialized with a single experiment, rather than multiple, and tiles it across specific subsets of qubits. You should be able to accomplish this by creating an experiment subclass (maybe called TiledExperiment) to do this. Eg tiled_t1 = TiledExperiment(t1, qubit_groups). Along this lines the BasicExperiment class also seems unnecessary, as this functionality along with the functionality of build_whole_expeirment could be built into a single TiledExperiment class.

API aside, I think there will be some edge case issues/failures with this approach of transpiling once for logical qubits then remapping transpiled circuits to different qubits for experiments that use pulse instructions based on backend properties for specific qubits/channels, so we should have some validation or handling for those cases.

Thanks @chriseclectic. I'll try to design an API following these guidelines. Note that BasicExperiment is an internal class that's required for the implementation.

Closing because work continues elsewhere